home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19981211-19990422 / 000345_news@watsun.cc.columbia.edu _Wed Mar 10 20:36:45 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Return-Path: <news@watsun.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA01257
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 10 Mar 1999 20:36:45 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA11089
  7.     for kermit.misc@watsun.cc.columbia.edu; Wed, 10 Mar 1999 20:08:21 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: C-Kermit Scripting using INPUT and LOG SESSION
  11. Date: 11 Mar 1999 01:08:19 GMT
  12. Organization: Columbia University
  13. Message-ID: <7c7523$aqe$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@mailrelay2.cc.columbia.edu
  15.  
  16. In article <36e7118d.0@amhnt2.amherst.edu>,  <jwmanly+news@amherst.edu> wrote:
  17. : I have some questions about how C-Kermit handles its internal buffers,
  18. : because I'm seeing some behavior that suggests it is more complex than I
  19. : thought.  In particular, I see in the C-Kermit help that there are separate
  20. : CLEAR command for DEVICE and INPUT, and I guess what I could use is some
  21. : information on how these two buffers are related -- that is, how does
  22. : information get moved from one to the other, and which one does LOG SESSION
  23. : read out of?
  24. : 
  25. The device buffer contains stuff that has not yet been read by Kermit.
  26. Kermit reads stuff out of the device buffer when it is in CONNECT mode or when
  27. you give it an INPUT command (and of course when you transfer files, DIAL,
  28. etc).
  29.  
  30. The INPUT buffer (a.k.a. \v(input)) is Kermit's internal circular buffer
  31. that stores the characters most recently read by INPUT commands.
  32.  
  33. : Basically, I'm trying to use C-Kermit to transmit some HTML form data to a
  34. : web-server, and extract a portion of the resulting returned web page.  I'm
  35. : sending the form data via the TRANSMIT command.  The web page that comes
  36. : back looks like this:
  37. : 
  38. : HTTP/1.1 200 OK
  39. : blah blah blah<p>
  40. : blah blah blah<p>
  41. : <font size="7"...<p>
  42. : THE DATA I WANT TO CAPTURE<p>
  43. : blah blah blah<p>
  44. : blah blah blah<p>
  45. : </html>
  46. : 
  47. : What I want is to capture the "THE DATA I WANT TO CAPTURE<p>" piece in an 
  48. : external file for further processing outside of Kermit.  I thought this
  49. : would be pretty easy: Just connect to the server, transmit the form data to
  50. : it, do an INPUT for the |<font size="7"| string, another INPUT to advance
  51. : to the following |<p>| string, turn on session logging, do another INPUT
  52. : for the |<p>| string, turn off logging, hangup and exit.
  53. : 
  54. : Well, needless to say it hasn't been this straightforward, and the results
  55. : don't even seem to be consistent. It is as if the LOG SESSION command is
  56. : working out of a buffer that is somehow different (or not synchronized)
  57. : with the one the INPUT command is using.  My actual script is down below,
  58. : but before we get to that, I've stumbled over some other strangeness as
  59. : I've tried to debug this issue, so let's go over those first.
  60. : 
  61. : Consider the following script:
  62. : ---------------------------------------------------------------------------
  63. : set host www.qrz.com:80
  64. : set input echo off
  65. : set transmit echo off
  66. : set transmit prompt 0
  67. : clear
  68. : transmit form.txt
  69. : log session form.out
  70. : pause 10
  71. : log session
  72. : hangup
  73. : exit
  74. : ---------------------------------------------------------------------------
  75. : 
  76. : This seems about as simple as it gets: transmit the form data, start
  77. : logging the session, wait 10 seconds for everything to come through, exit.
  78. : This should record everything that comes back.  But it doesn't.  In fact,
  79. : it doesn't record anything.  BUT, if I replace that "PAUSE 10" command with
  80. : an "INPUT 10 XXXXXXX" string, THEN it works.  
  81. : 
  82. : Why is this?
  83. :
  84. Because after you "transmit form.txt", you are not executing any Kermit
  85. commands that read from the connection.
  86.  
  87. : Why the necessity for the INPUT line? I assume it is to force
  88. : C-Kermit to somehow "consume" or "process" the information, but is there
  89. : any other, cleaner way to do that?
  90. : 
  91. No.  You have to think of INPUT as an analog for your eyes and brain.
  92. If you were in CONNECT mode, you'd watch the stuff coming in, and eventually
  93. you would see something that tells you it's done.  No INPUT, no eyes (and
  94. no brain :-)
  95.  
  96. (OUTPUT is an analog for your fingers, and some would say also for your
  97. brain, but others -- especially readers of certain newsgroups (not this one)
  98. might disagree :-)
  99.  
  100. : OK, on to my real problem.  Consider the script below, the one to solve the
  101. : problem I describe at the start of my message:
  102. : 
  103. : ---------------------------------------------------------------------------
  104. : set host www.qrz.com:80
  105. : set input echo off
  106. : set transmit echo off
  107. : set transmit prompt 0
  108. : clear
  109. : transmit form.txt
  110. : input 10 <font size="7"
  111. : input 10 <p>
  112. : log session form.out
  113. : input 10 <p>
  114. : log session
  115. : input 10 </html>
  116. : hangup
  117. : exit
  118. : ---------------------------------------------------------------------------
  119. : 
  120. : This doesn't work reliably, though it does work sometimes.  
  121. :
  122. So maybe it's time-dependent.  Something that takes 10 seconds one day on
  123. the Internet might take an hour on another day.  You need IF FAIL tests
  124. after every INPUT.
  125.  
  126. : Final question: notice how I put that "INPUT 10 </html>" command at the end
  127. : of the script to flush out whatever other data comes back from the remote
  128. : server following the part that I am intersted in?  If I don't do this, when
  129. : I hit the EXIT at the end of the script (even though it follows the HANGUP
  130. : command), I get the "There may still be a connection open, OK to exit?"
  131. : message when the script finishes.  I assume this is because there is
  132. : "unconsumed" data in the buffer.
  133. :
  134. It's because the connection is still open, just like it says.  The server
  135. closes the connection after all the data it sent has been acknowledged
  136. (at the TCP level).
  137.  
  138. : How do I tell Kermit to drop the
  139. : connection regardless of whether there is anything left in the buffer or
  140. : not, even if data is still streaming in?
  141. : 
  142. Like it says in the book:
  143.  
  144.   SET EXIT WARNING OFF
  145.  
  146. There are some examples in the book that should clarify matters.  E.g, how
  147. to read a line at a time from the host and write each line to file as it
  148. comes in.
  149.  
  150. - Frank